1. Field of the Invention
The present invention is directed to computer systems. More particularly, it is directed to verification of portability of computer system applications.
2. Description of the Related Art
The complexity and expense of developing and deploying enterprise-level computer systems applications has been increasing over time. In addition to supporting a rich set of functional features, a modern enterprise application may also have to be scalable enough to support large numbers of concurrent users, and provide a high level of availability, maintainability and interoperability with other applications. The development cycle for a single major release of an application may take months or even years, and may require hundreds of person-years of development resources. As a result, enterprise application vendors are understandably eager to reduce the total cost of application development.
In the past, application vendors often developed a first version of an enterprise application for a particular execution platform (e.g., a combination of a computer hardware architecture and an operating system designed for the hardware architecture), and then ported the application to other execution platforms as needed. Each ported version of the application typically went through a quality assurance test cycle on the corresponding platform. Quality assurance testing, during which the functionality, performance and other features of the enterprise application are tested, often represents a substantial portion of the total expense of application development. In order to reduce porting and testing costs, and also in response to growing customer demand for applications that can be deployed across a variety of hardware architectures and operating systems, in recent years many application vendors have begun to target their applications to application server environments (such as the Java 2 Enterprise Edition (J2EE™) environment) that are intended to be platform-agnostic. Typically, a standards organization (or a collaborative body such as the participants in the “Java Community Process” in the case of J2EE™) is responsible for defining standards for the application server technology in the form of formal specification documents. The specification documents define the functionality and interfaces that must minimally be supported for compliance with a particular version of the application server technology. As application server is typically designed and advertised as being compliant with a particular version of an application server technology, and potential users and developers may consult the specifications associated with that version to determine the set of features supported by the application server. Applications developed in accordance with a particular version of a specification are expected, in principle, to be deployable without source code modification at any application server that conforms to that version of the specification (e.g., simply by modifying runtime deployment descriptors), regardless of the specific operating system or hardware architecture of the platform on which the application server is executed. Thus, once an application vendor has developed and tested such a portable application on an application server on one platform, no further source code changes should be required to deploy the application on other platforms, and the application vendor should also be able to reduce or eliminate additional testing required for the other platforms.
Unfortunately, application servers provided by different application server vendors may differ slightly in the set of functions and features provided, even where the different application server vendors claim compatibility with the same set of specifications. For example, the specifications may allow optional features or extensions to be implemented, and different application server vendors may implement different sets of optional functions. As a result, an application developed on a particular application server may sometimes use features such as application programming interfaces (APIs) that are vendor-specific. Also, some development environments may support the use of so-called “wrapper” APIs that may allow developers to utilize standard APIs through non-standard intermediary interfaces that may be easier to use than the standard APIs. Both vendor-specific and wrapper APIs may make applications non-portable; that is, applications using such non-standard features may work as designed at one vendor's application server, but may fail at another vendor's application server, even when both vendors claim to support the same standard specifications. Some applications using non-standard extensions may even work at application servers from more than one vendor (e.g., if two or more vendors implement some of the same non-standard extensions) and hence may be considered at least somewhat portable; in general, however, applications that use non-standard extensions may not be guaranteed to work at all application servers that support the same standard specification and thus may raise portability concerns. Application customers that do not wish to be dependent upon specific vendors, and application developers tasked with developing portable applications, may therefore wish to determine whether a given application is truly portable.
Some traditional tools for identifying non-portable features of applications may require access to application source code, which may not be easily accessible to customers. Other conventional tools may attempt to build a repository of non-standard features or APIs for various application server components, and check whether any of the non-standard features are used in an application. However, it may be difficult to accurately track the set application server extensions being supported by all the different application server vendors. As a result, an approach that relies on maintaining an exhaustive list of non-standard features may not be accurate or complete in its identification of the non-portable features of an application. In addition, portability criteria may change over time (e.g., as standards or specifications change), and traditional portability verification tools may themselves require source code modifications to adapt to changes in portability criteria.